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I. INTEOD CCTION 



The joint deployment commurity is dependent upon elec- 
tronic exchange of data for successful operations. Current 
systems do not provide the necessary commands the ability to 
communicate quickly ana efficiently, causing information 
exchange delays and erroneous or out-of-date data to be 
transmitted. Both planning and execution phases of deploy- 
ment operations are adversely affected. 

The Electronic Data Interchange (EDI) concept has been 
proposed as a system for realizing a distributed database 
approach to information management, the approach required by 
the Joint Operation Planning and Execution System {JOPES) . 
The EDI concept provides a means for electronic interface 
among commands which do not have the same hardware, soft- 
ware, or database management systems. While there are many 
factors to be considered when implementing a community-wide 
system, and not all concerns or issues can be addressed by 
any one system, perhaps one of the most basic issues is the 
feasibility of implementing an exchange system such as the 
EDI system. 

This thesis demonstrates the feasibility of implementing 
the EDI concept throughout the joint deployment community. 
It also describes the connection between service unique 
systems and the system supporting the joint deployment 
syst em. 

Chapter II provides background by defining the Joint 
Deployment System. Its current planning and execution 
systems are outlined. The EDI concept is then examined, and 
its applicability tc the present system is described. 
Chapter III examines the EDI concept in depth. The 
mechanics of the system are explained, and a generic 
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description of how such an interface is accomplished is 
given. Chapter IV contains a description of the scenario 
and data elements used to demonstrate the proposed inter- 
change system, and the results of the demonstration. 
Chapter V is a discussion of current service unique systems 
which exist at different levels through the joint deployment 
community. These service unique systems are examined with 
respect to their interface, both current and potential, with 
the joint deployment system. limitations of the EDI concept 
are also explored. Chapter VI discusses factors which must 
be considered when implementing this system. Implementation 
benefits which can be realized through the use of the EDI 
concept are then summarized. 
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II. B ACKGBOOND 



The Joint Deployment system (JDS) "consists of 

personnel, procedures, directives, communica tion systems, 
and electronic data processing systems to directly support 
time-sensitive planning and execution and to complement 
peacetime deliberate planning." [Ref. 1] The community 
which is directly concerned with the JDS ranges from organi- 
zations at the NCA level down to the actual deployable 
fighting units. The amount of information exchange neces- 
sary to provide all concerned with appropriate, timely, and 
accurate information is staggering. 

A. PIANflING 

There are two distinctly separate types of planning 
within the JDS. The Crisis Action System (CAS) is concerned 
with planning under time-sensitive or crisis situations. 
Deliberate planning is planning during peacetime, non-crisis 
operations. Planning for joint military operations and 
force deployment is conducted using the Joint Operations 
Planning System (JOPS). JOPS consists of policies, proce- 
dures, and systems used to support force deployment plan- 
ning. The ADP portion of JOPS operates on the Worldwide 
Military Command and Control System (WWMCCS) computer 
system. [ Ref. 2 ]. 

1 ♦ deliberate P la nninq 

There are five phases to deliberate planning: 
initiation, concept development, plan development, plan 
review, and supporting plans. These phases are depicted in 

Figure 2.1 [Ref. 3: p. 5]. The first two phases are 
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concerned with defining the threat and establishing an 
appropriate concept of operations. The third phase, plan 
development, has as its objective a "transportation 
feasible, implementable plan." During Phase IV, plan 
review, the plan is revised, taking into account adequacy, 
feasibility, suitability, and the dynamics of change. An 
approved plan is ultimately produced. Phase V produces a 
family of supporting plans, taking into consideration 
service doctrine and support agreements. 

The primary document associated with deliberate 
planning which outlines deployment requirements is the time- 
phased force deployment data (TPFDD) . This is created 

during the Plan Development phase, and at this stage 
contains the information, on a notional basis, needed to 
describe a deployment. 

The Transportation Operating Agencies (TOAs) are 
responsible for preparing movement schedules which support 
requirements established by the TPFDD. In order to accom- 
plish this, the TPFDD goes through an extensive refinement 
process, with actual forces identified to replace the 
notional forces. Additionally, specific transportation 
requirements and unique deployment situations are identi- 
fied. The execution feasibility of identified scheduled 
movements is tested by the appropriate TOAs, using service 
unique systems and software. The TPFDD and the associated 
OPLAN are eventually reviewed and approved by the JCS, and 
the TPFDD is then entered into the deployment data base at 
the Joint Deployment Agency {JDA) . When completed, the 
TPFDD contains time-phased force data, non- unit-relate d 
cargo and personnel data, and transportation data for the 
operation plan, including supporting units with associated 
priorities, routing of forces to be deployed, associated 
mobility data, and cargo and personnel movements to be 
conducted concurrently with the deployment of forces. 
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PHASE I 
Initiation 



Basis: National Security Objectives 

Criteria: The Threat 

Planning Tasks and Forces 

Objective: To Set the Stage 



PHASE II 

Concept Definition 



Basis: Mission Assignment (Forecast Assignment 

Criteria: Force and Resource Allocation 

All Significant Factors 
Concept Adequacy 
Objective: Derive the Concept 
of Operations 



PHASE III 
Plan Development 



Basis: The Commander's Concept 

Criteria: Force and Resource Allocation 

Service Planning Factors 
Strategic Movement Data 
Objective: A Transportation Feasible 
Implementable Plan 



PHASE IV 
Plan Review 



Basis: The Plan 

Criteria: Adequacy and Feasibility 

The Dynamics of Change 

Objective: An Approved Plan 



PHASE V 
jppor ting Plans 



Basis: The Approved Plan 

Criteria: Service Doctrine 

Support Agreements 

Objective: A Family of Plans 



Figure 2. 1 Phases of Deliberate Planning 
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[Ref. 4] This refined TPFDD is accessible to the deployment 
community and can be updated, tc some extent, by the TOAs as 
required. Continual interacticn between JDA and the TOAs, 
as well as interaction between two or more TOAs, is neces- 
sary for the successful refinement of the TPFDD. Various 
stages of refinement require interaction at conferences, via 
telephone, and via computer systems which support the JDS. 
Once the TPFDD is established, interaction is primarily 
through the computer systems. Efficient, accurate interac- 
tion is necessary for the deployment data base to accurately 
reflect troop/supply movement, as well as changing require- 
ments cr force assignments. 

2 • Cr isis Action Planning 

The Crisis Action System provides a framework within 
which time-sensitive planning can be accomplished. The 
procedures are intended to provide each level of command the 
information necessary to develop timely recommendations to 
aid the NCA in making decisions involving U.S. military 
forces in the execution of military courses of action. 
[Ref. 5; p. II-1 ] 

There are six phases tc the crisis action system, 
which are outlined in Figure 2.2. Both the TOAs and JDA are 
involved immediately in any crisis action planning. During 
Phase I, the joint deployment community monitors the situ- 
ation, as JDA ensures that the joint deployment system is 
operational. During Phase II, as existing OPLA Ns are being 
assessed at the NCA level, the crisis action teams at the 
TOAs and JDA are activated and plans are assessed at that 
level as well. Coordination between the CINCs involved and 
the joint deployment community also takes place. During 
Phase III coordination between the CINCs, the TOAs and JDA 
increases, as the TOAs prepare preliminary deployment esti- 
mates based on commanders' estimates. JDA is also involved 
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Figure 2.2 Phases of the Crisis Action System 




with coordinating the estimates from the TOAs and providing 
both JCS and CINCs with the consolidated estimates. 
Throughout the execution phases the TOAs and JDA continue to 
update and coordinate the force deployment data base as 
actual movements are initiated and completed, and as 
requirements change during the conflict. [Ref. 5: pp. II-2 
- II- 9 ] 

During Phase V the TOAs begin actual scheduling, 
concentrating on the first six days for air and the first 30 
days for sea transportation. JDA verifies the accuracy of 
the data base before the TOAs fcegin their scheduling, and 
resolves transportation problems between TOAs, supporting 
and supported commanders. During Phase VI the TOAs and JDA 
continue to manage and coordinate transportation require- 
ments, respond to changes, report deployment deviations and 
diversions in JDS, and provide deployment status to those 
concerned, from the TOA level tc the JCS. 

3. Joi nt Operation P la n Ei nq and Executio n S yste m 

(JOPES) 

The Joint Operation Planning and Execution System 
(JOPES) concept was approved in July 1983, and was envi- 
sioned as: 



the foundation for cur conventional command and control 
system. JOPES will support monitoring of readiness, and 
monitoring, planning. and execution of mobilization, 
deployment, employment, and sustainment activities both 
in peacetime and under crisis and wartime conditions. 
[ Ref. 6: p. 1 ] 



JOPES came into being primarily because of the extensive 
redundancy of JOPS and JDS. Although they are two separate 
systems, the functions and products of each are so entert- 
wined that neither system functions efficiently without 
considerable interaction with the other. Although not yet 
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fully operational, JOPES will consist "...of the policy, 
procedures, software, hardware, personnel, training, and 
connectivity necessary to facilitate planning, directing, 
coordinating, monitoring and controlling military opera- 
tions." [Ref. 7] The effective implementation of such a 
system will require a distributed data base structure within 
the ftWMCCS community. 

B. SERVICE UNIQUE AUTOMATED SYSTEMS 

There are numerous automated systems throughout the 
services which are related, in varying degrees, to the 
deployment community as a whole, and to the joint deployment 
system. Figure 2.3 lists some of these systems, and indi- 
cates their interrelationships. It should be obvious that 
an interface between key systems involving data required to 
effectively plan and execute fcrce deployment would greatly 
enhance the effectiveness and efficiency of such operations. 
Although not as clearly indicated in Figure 2.3, interfaces 
between differing commands using the same systems frequently 
either are not fully automated, or have inherent sericus 
time delays which create data mismatches and inaccuracies . 

The automated systems throughout the joint deployment 
arena are constantly changing and growing to meet the needs 
of the community. Many of the problems identified two and 
three years ago have been partially or completely solved 
since then. There are still, however, significant problems 
concerning the implementation cf required interfaces. As 
service-unicue systems proliferate, interface requirements 
become both more numerous, and easier to accomplish. For 
example, as a system which automates unit requirements data 
comes on-line, it creates a need for an interface which can 
provide that data, in required format, for use by transpor- 
tation agencies within the deployment community. While this 
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figure 2.3 lohil izat ion /Deployment Automated Systems 



creates a need for an interface# it also simplifies the 
problem of data exchange# as automated interfaces are faster 
and easier than providing that same data manually from the 
original data location to the TOAs for input in the joint 
deployment system. 

The necessity for interfaces between appropriate systems 
(and appropriate commands withir the same system) is widely 
recognized. Implementation on a significant basis# however# 
has not teen accomplished. 

C. EXISTING INTEBFACE METHODS 

There are a variety of methods currently in use for 
accomplishing data transfers. For those organizations not 
in the WWMCCS Intercomputer Network (WIN) # there are essen- 
tially two means available for transmitting information 
between physically separate locations. As antiquated as it 
may seem# one primary method is the use of the-U.S. Postal 
Service. In numerous instances# actual output listings from 
the different systems are mailed to the units# the units 
make pen and ink changes as the status of forces and equip- 
ment changes# then the listings are mailed back to the 
computer site for update to the actual file. In the 

Interim, continuous telephone communication between the 
parties involved helps keep the files from becoming 
uselessly out of date. 

In other cases# the existirg AUTODIN is used to provide 
either tape-to-tape or card-to-card transfer of data. In 
either instance# when AUTODIN is used there is a consider- 
able human interface required which not only slows the 
transfer process but always introduces an unnecessary error 
factor. 

A third, significantly more efficient# method of data 
transfer in use today is the WIN. For those locations 
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having access to WIN the human interface is minimized. WIN 
not only allows for automatic tape-to-tape transfers tut 
also provides a means of compu ter-to-compu ter disk transfer. 
Disk-to-disk transfers are considerably faster and more 
efficient than tape-to-tape. This is primarily due to the 
sequential nature of a tape transfer. When automatically 
sending data over communications lines, there is always the 
danger of a break in communications service, a ’timeout 
period’. Under the present WIN system, once a tape transfer 
is interrupted, for whatever reason, it is physically impos- 
sible to restart the tape at some point in the middle. This 
means that the sending tape is rewound and the entire tape 
retransmitted. Tape-to-tape transfers are an all too common 
occurrence in interfacing the systems within the WKdCCS 
today. Although WIN disk-to-disk transfers are considerably 
more efficient, the present need for standardization of both 
the software and hardware required to accomplish the 
exchange introduces another more complicated issue. 

D. STANDARDIZATION 

One of the methods suggested to accomplish the necessary 
interchange of information is comm uni ty- wide standardiza- 
tion. This method has traditionally been used in the 
computer industry, for several reasons. Initially, this was 
the only alternative available; technology was not readily 
available which would permit any meaningful communication 
between different vendors' equipment. It was only with the 
advent of numerous companies and systems and the resulting 
profusion of previously incompatible equipment that efforts 
were made to develop methods of computer-to-computer 
communications. 

The first generation of interfaces required a consider- 
able amount of standardization. Programs which translated 
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from one system to a totally different system were designed 
primarily as one-time conversion opportunities. Whether for 
technological or commercial reasons, standardization was 
considered necessary. 

The next stage in the evolution of computer communica- 
tions involves interfaces that eliminate the need for stan- 
dardization. These are, however, relatively new, and are 
not as well known or understood as standardization. Perhaps 
because of this, the standardization solution to the data 
exchange problem throughout the joint deployment community, 
as well as elsewhere, has been proposed by many concerned 
with the issue. Certainly standardization of data elements 
and format (and possible hardware as well) would provide the 
opportunity for automated data exchange. Unfortunately, 
there are also significant drawbacks to standardization. 
The most obvious may be that the joint deployment community 
already abounds with guite a variety of "non-standard" hard- 
ware and software. The conversion in equipment costs alone 
becomes impractical. Equally as important, however, is one 
of the underlying reasons for the existence of the differing 
software and hardware: differing applications needs. 

The commands within the joint deployment community are 
responsible for different missions, and their daily require- 
ments emphasize different aspects of the deployment picture. 
The same transaction (e.g. , shipment of tanks from Ft. Ord, 
California to Misawa, Japan) is of differing importance to 
different levels in the joint deployment community (the 
initiating unit, the Transportation Operating Agency 
involved, the unit assigned to carry the tanks, and the 
Joint Deployment Agency) . The importance of individual data 
elements involved in this transaction vary from command to 
command. Additionally, each command involved has ether 
reporting requirements within its own service which require 
data in certain format. To require identical data element 
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formats and transmission structures at each node of this 
transportation operation would introduce inefficiencies on 
the local level. That is, data elements either not neces- 
sary or formatted differently at a local level may, for the 
"good" of the community, become leading data items which 
must be formatted and/or transmitted differently. A further 
complication can be illustrated when items as simple as a 
shipping date are standardized. Different commands may 
organize filing or retrieval systems by day or month; 
reguiring every command in the joint deployment system to 
place the day first introduces unnecessary confusion at 
those locations where other daily tasks require the month 
first. 

E. ELECTRONIC DATA INTERCHANGE CONCEPT 

Electronic Data Interchange (EDI) is a computer-to- 
computer data exchange system designed to be used by both 
industry and government. The EDI system objective is to 
develop and maintain standards for the electronic inter- 
change of data between any tyje or size of companies or 
government agencies. These standards were developed in a 
joint industry/government program sponsored by the United 
States Department of Transportation. In order to accommo- 
date the requirements of the majority of potential users, 
the Transportation Lata Coordinating Committee (TDCC) was 
assigned the task of establishing and maintaining the stan- 
dards. TDCC in 1985, recognizing that potential applica- 
tions of EDI systems were not limited to the transportation 
industry, changed their name to EDI Association. The first 
set of EDI standards, published in 1975, coordinated the 
requirements of ocean, air, motor, and rail carriers. In 
addition, these same standards were designed to meet the 
needs of the users of the carrier services. Subsequent 
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enhancements have been made to the EDI standards in response 
to reguests from the user community. 

The EDI software uses a ’table-driven* technique to 
generalize processing regardless of the application being 
processed. Specific directiors are taken by the software 
depending on the data being processed and the particular 
tables associated with the applications. The EDI software 
resides in each participants' computer system and is an 
interface between EDI format structures and the partici- 
pant’s internal system. The EDI software assumes that an 
EDI participant already has an automated system in use for 
processing internal applications. Some of these internal 
applications require data from external (outside the partic- 
ipant's system) sources or provide data to external points. 
The format for these interagency data transfers is given in 
the EDI standards. EDI is not an independent system but is 
meant to interface existing in-house systems. TDCC EDI 
software eases the transition from a completely closed 
internal system to an internal system with a controlled 
external interface. [Ref. 8] 

EDI, Incorporated is a company independent of the TDCC 
with a staff which works as systems consultants to TDCC and 
has comprehensive and detailed knowledge of the EDI stan- 
dards and the TDCC software. EDI, INC. has performed a 
significant role in the industry-wide acceptance of the EDI 
standards as a viable means cf data interchange. This 
company, under contract, designed the software to link users 
in the grocery industry, the transportation industry, and is 
currently under contract with the Military Sealift Command 
and the Military Traffic Management Command. 

The emphasis of the EDI concept is on the exchange of 
information between computers through the use of standard 
transaction sets. This provides one of the major benefits 
of such a system: the users preserve their autonomy while 
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efficiently interfacing with ether users. There is no 
requirement for different users to use the same hardware, 
software, or even data base management systems. This also 
provides the additional benefit of being able to add or 
delete individual data elements without requiring software 
logic changes. [Ref. 7; p. 42] 

The FDI interface creates a data exchange structure in 
the format depicted in Figure 2.4. With this structure 
modifications to one user’s applications do not affect other 
users. The interface software is between the individual 
user and the standard data set. Once all nodes of the 
structure can interface with the standard, data exchange can 
be accomplished between any twe nodes, with no additional 
interface requirements necessary for communication between 
the two nodes. The interface acts as a transparent partner; 
from the user’s viewpoint the communication is directly with 
the second user. The overall number of interfaces required 
for communication between all nodes is therefore reduced (to 
four in the example in Figure 2.4 from six if the standard 
transaction set was not available). [Ref. 7: p. 34] 




Figure 2.4 Interfacing Through a Standard Data Set 
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F. 



SUMMARY 



It should be apparent that the flow of information 
between relevant commands during both deliberate planning 
and crisis actions must be timely and accurate. The data 
base required to support such planning and execution must be 
accessible to all involved, and must be kept current. Thus, 
effective interchange of information necessitates a network 
which is, as much as possible, automated, easy to use at 
each node, and reliable. The EDI concept Is one proposal 
available to accomplish this interchange. The resulting 
network should encompass service unique automated systems as 
well as the specific computer system supporting JDS. 
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III. E LEC TRONIC DATA INTERCHANGE 
A. INTRODUCTION 

Data interchange is concerned with the transmission and 
interpretation of information among participants. The 
proposed EDI interface is a computer-to-computer data 
exchange system which utilizes a disk-to-disk transfer. Its 
purpose is to simplify the integration of external communi- 
cations with internal applicaticns programs. The previous 
chapter introduced the EDI concept; this chapter will 
describe in some detail the mechanics of the interchange 
system. Areas of importance include the EDI software and 
the data and format structures. Definitions of concepts 
which are integral to an understanding of the following 
discussion are: 



Interfa ce System: Interface system refers to the 

computer programs to be used to construct or edit infor- 
mation communicated between electronic data interchange 
systems and the internal applications programs of a 
participant. 



Electronic Data Interchange: Electronic data inter- 
change means the "transmission of transaction data, in 
formats selected in the EDI standards, between two or 
more companies or organizations having business rela- 
tionships. 



Int erna l Applications: Internal applications refers to 
the use of electronic data processing eguipment to 
support internal operational information functions. The 
electronic data interchange system interfaces with but 
does not include internal applications. [Ref. 9] 



It must be emphasized that the EDI concept represents an 
interface between existing internal automated systems and 
external automated systems. It supplements existing systems 
in that data transfer and communication are enhanced. The 
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EDI system does not provide internal data manipulation capa- 
bilities, nor will it (of itself) produce such things as 
reports, data summaries, or OPLANs. 



B. EDI SOFTWARE 



The EDI software resid 
system, and provides an in 
EDI format structures. Thi 
internal system’s automated 
other commands. When rece 
the same software puts in 
Objectives for the EDI softw 



es in each command's computer 
terface between that system and 
s software extracts data from an 



data 


bas 


e for 


transmission to 


ivi ng 


data 


from 


other commands. 


formation 


into 


the data base. 



are are: 



To automatically generate and interpret data 
To process transaction sets. 

To ensure common interpretation of transmission by both 
the sender and receiver. 

To code information when practicable. 

To use fixed format standards. 

To eliminate data net likely to be used. 

To allow for flexibility so that the standards may be 
enhanced as needs change or evolve. [Ref. 9: pp. 2-3] 



1 . Sof twar e O pe r ati on 

The key to EDI software operation is its method of 
transmission. The required data is first transformed into 
EDI transaction sets, then transmitted in standard, 
compressed format. Upon receiving a transmission, the soft- 
ware 'explodes' the compressed data into fixed format 
records defined by the receiving user which are compatible 
with the user's internal software and database. The order 
of elements in a given user's record structure does not have 
to be the same as that used by the EDI software. Software 
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procedures and interfaces rear 
The EDI software uses a column 
EDI tables (Table 4, explained 
stand' the locations cf given d 
between EDI software and the 
diagrammed in Figure 3. 1 Those 
make up the EDI software. [Ref 



range the data a 
of information i 
below) in orde 
ata elements. Th 
user’s overall 
modules within 



s necessary, 
n one of the 
r to 'under- 
e interfaces 
system are 
the dark box 



. 9: p. 28]. 



2 . T ables 



To facilitate change a 



ware is 


'table-driven' . 


The 


parameters 


for use by the 


prog 


the EDI 


software are as follow 


Table 


1: 


Set Pointers 




Table 


2: 


Segments for 


Each 


Table 


3: 


Segment Pointers 


Table 


4: 


Data Elements 


for 


Table 


5: 


Data Elements [Ref 



nd modification, t 
tables define form 
ram. The five ta 
s : 

Transaction Set 

Each Segment 

. 9: pp. 43-44] 



he EDI soft- 
ats and edit 
bles used by 



Their functions are described in Figure 3.2 [Sef. 9: p- 35]. 
The same five tables used for generation of data tc be 
transmitted are used for interpretation of received data. 
The software programs maintain pointers to the tables. 
These pointers are moved as necessary during processing in 
order to edit or generate data formats. 

3. So f tw are Programs 

There are two EDI operational software programs: 
Set Generator for transmission and Set Interpreter and 
Parser for reception. These programs, in addition to main- 
taining table pointers, use the information at the pointer 
locations in conjunction with information from the internal 
data base to assure program operation and interpretation of 



27 



r 
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Figure 3. 1 Data Interchange Program Modules 



data. The Set Generator, 
composes transaction sets in 
The Parser extracts data ele 



using the above information, 
proper transmission structure, 
ments from the continuous stream 
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Table 1 is used to locate items in Table 

2 . 



Table 2 gives the order of segments in a 
transaction set for each application. 



Table 3 is used to locate items in Table 

4 . 



Table 4 


gives the order of data 


elements 


in each 


segment 


• 




Table 4 


example 


(simplified) : 




Segment 

• 


I.D. 


Data Element 


Location 


# 

• 

EX (Exajnple) 


D 


11 


EX 




A 


1 


EX 




E 


13 


EX 




C 


9 



Table 5 specifies data element attributes. 
Table 5 example (simplified) : 



Data Element 

A 

B 

C 

D 

E 

F 



Maximum Length 

4 

4 

2 

2 

12 

8 



Figure 3.2 The Five EDI Tables 



of characters received, and forwards the data to the Set 
Interpreter. The Set Interpreter edits incoming transaction 
sets. The resulting data is passed to the internal applica- 
tions routine. 



C. EDI DATA AND FOE HAT STRUCTURE 
1 . Data Dictionary 

All EDI system transaction segments and transaction 
sets are constructed from basic building blocks which are 
contained in the Data Dictionary. Within this ' die tionar y ' , 
all data elements are defined in a standardized format. 
This does not indicate a need for standardization among 
commands, however. The internal systems used by commands 
will interface with this ’centralized' standard through the 
interchange. The data dictionary includes the following; 



- Data Element Number 

- Data Element Name 

- Data Element Description 

- Field Length 

- Characteristics 

- Reference Designators [Ref. 10; p. 153] 

Appendix A is an example of part of a data element 
dictionary. The first five items above are self- 
explanatory; the reference designators refer to the trans- 
action sets in which the particular element is used. 

2. Units of Information 

There are three basic units of information used in 
the EDI data interchange. These units may be of variable 

length and relate to each other as shown in Figure 3.3 
[Ref. 10: p. 5]. 
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INFORMATION UNITS 
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,000: 


l 0000: 
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Figure 3.3 KOI Information Units 



They are defined as fellows 



Data Element: The smallest information unit in the EDI 

information structure is the data element. A data 
element may be a single character code, a series of 
characters constituting a literal description or a 
numeric guantity. 

Data Segment : A data segment is composed of a function 

Identifier and one or more functionally related data 
elements positioned serially in a standard manner. 

Transaction Set: A transaction set is that group of 

sfar.dard data segments, in a predefined sequence, needed 
to provide all of the data reguired to define a complete 
transaction such as purchase order, invoice, bill of 
lading, or freight till. [Ref. 9: pp. 4-6] 



Additionally, transaction sets 
groups, which are combined for 
segments are inserted througho 
ensure communication coherency, 
called format units and are 1 
ending of segments, as shown i 
Except where noted, these segm 
not pictured, there are als 
segment and data element levels 
Each data segment begin 
identifier 1 and ends with a 'da 
first is composed of aipha/nu 
latter is either an EBCDIC c 



[Ref. 9: p. 6]. At the data 
is known as a 'data element de 
by an It follows each dat 

the last (it also fellows the 
asterisk is also transmitted wh 
transmitted for a defined el 
element in a segment. This 
count. The information requi 
data segment is depicted in Fig 



are grouped into functional 
transmissions. Appropriate 
ut these levels in order to 
These additional units are 
ccated at the beginning and 
n Figure 3.4 [Ref. 9: p. 7] 

ents are required. Although 
c format units at the data 



s with a unique ' data segment 
ta segment terminator'. The 
meric characters, while the 
ede or ASCII code character 
element level the format unit 
limiter' , and is represented 
a element in a segment except 
segment identifier). The 
enever there is no data being 
ement other than the last 
preserves the data element 
red to completely describe a 
ur e 3.5. 
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Cjnnum cat ions Protocol 



Transmission Control Header Segment (BG) 
Functional Control Header Segment (G5) 



Transaction Set Control Header Segment (ST 
(Beginning Segment) 



Oetail Cata Segments 
(e.g. Purcnase Croer) 



Transaction Set Control Trailer Segment ( S£ ) 
(Ending Segment) 

Transaction Set Control Header Segment (ST ) 
(Beginning Secrr.ent) 



Detail Cata Segments 
(e.g. Purcnase Croer) 



• Transaction Set Control Trailer Segment (SE) ■ 
(Ending Segment) 



Functional Control Trailer Segment (GE5- 
Functional Control Header Segment { G 5 ) 



Transaction Set Control Header Segment (ST ) 
(Beginning Segment) 



Cetail Data Segments 
(e.g. Receiving ^vice) 



Transaction Set Control Trailer Segment (SE)- 
(Ending Segment) 



Functional Control Trailer Segment (GE) 
Transmission Control Trailer Segment (EG) 
Cormum cat ions Protocol __________ 
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Figure 3.4 Transmission Structure 
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N 



10 



N101 98 



\ 



Organization 
1 | | Identifier 

i i M AN 02/02 1 



93 1 



N102 
Name 
C AN 01/35 



1 



N103y 66' 

ID Code 1 
Qualifier 
P0304 | 

C AN 01/02 i 



N104 



67 



ID 

Code 
P0304 
C AN 02/17 



I 

i 




63 CHARACTERS MAXIMUM LENGTH 



8 3 5 

1 - Set Identifier 

2- Reference designator: Segment identifier followed 
by sequence number within segment 

3 — (A) Alpha; (N) Numeric; (AN) Alpha/Numeric; 

(Dn) Implied Decimal (with n places to right 
of implied decimal point), (R) Decimal (with 
decimal point explicitly required), (NZ) Numeric— zero 

4— Data element name 

5— Minimum/maximum number of characters 

6- Data element reference number 

7- New line character or carriage return, line feed 

8 - (M) Mandatory; (C) Conditional; (O) Optional 

9- Special relational conditions 
10- Delimiter 



Figure 3.5 Transaction Segment Format 



3. Communications Interface 

Ihe EDI software utilizes 512 character blocks. 
Existing communica tions may utilize blocks of other lengths. 
There is no need to change either the EDI software or the 
length required for the comnunica tions protocol. The 
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communications software used should adapt to both lengths, 
as indicated in Figure 3. u [Ref. 9: pp. 42, 44 ]. 



COMMUNICATIONS 




Figure 3.6 Communications Interface 



D. SUHUARY 

The EDI concept provides an interchange between auto- 
mated systems internal and external to a command or organi- 
zation. The software resides within a command's system, and 
uses a table-driven technique to allow for generalized 
processing, regardless of the application being processed. 
It is generic in that no specific hardware or software is 
required, and in fact many different vendors may be used 
with no degradation in system capabilities. 

Within the EDI software, data elements, data segments, 
and transaction sets are used to convert differing formats 
to standardized format for transmission, and again at the 
receiving end to reconstitute the transmission into formats 
acceptable to the receiver. As should be obvious after the 
generic description of the software mechanics throughout 
this chapter, this concept is applicable at many different 
levels throughout the joint deployment community, as well as 
elsewhere in DOD. 
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IV. DEMONSTRATION 



A. INTRODUCTION 

As discussed in Chapter II, the joint operation planning 
procedure is an ongoing, day-to-day process. Operation 
Plans (OPLANs) are continuously being developed and revised 
to ensure there is an OPLAN designed to meet any anticipated 
contingency. An integral part cf every OPLAN is identifica- 
tion of those military units reguired to implement the given 
plan. Once specific units are identified, the Joint 
Deployment System comes into play in determining the trans- 
portation assets needed to deploy those units to the oper- 
ating location. This process is also an ongoing, continuous 
procedure. As OPLANs are revised, the transportation needs 
may change; as units acquire new equipment or modify the 
old, their transportation needs, again, may change. 

In order to ensure that the transportation assets are 
available to fulfill the requirements of any OPLAN, the 
Joint Deployment Agency, as part of the JDS, maintains a 
central data base containing all of the specific information 
regarding the deployment needs cf every military unit. This 
is necessarily a very large, complex data base and it is 
easy to visualize the tremendous task involved in keeping 
the data current and accurate. The specific procedures 
employed to modify and update this data base vary depending 
on the unit, the service, and TCA involved in the particular 
scenario. In any case, the applicability of an automated 
interface between JDS and the organization involved in the 
data update process is obvious. 

For the purpose of demonstrating the feasibility of 
using the EDI system of data interchange in the deployment 
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arena, we developed a scenario involving one unit, one TOA , 
one command headquarters, and the JDA. It is important to 
remember that what we are demonstrating is only one very 
small portion of the overall communications process and data 
transfer which transpires routinely in maintaining the JDS 
data base. 

In this scenario development, we will first identify the 
agencies selected to exemplify the ’typical’ data fiow, then 
discuss how these agencies are currently accomplishing the 
task of maintaining the data on a daily basis, and then pose 
a crisis situation which requires that the actual system be 
forced into action. Finally, we will show an example of the 
same automated systems interfaced using EDI as compared with 
the current procedures. 

B. SCENARIO 

We selected the Army’s Military Traffic Management 
Command (MTMC) as the TOA involved in the transport of the 
deploying unit. In particular, we selected the 7th Infantry 
Division out of Ft. Ord, CA as the unit to be deployed. The 
geographical location of Ft. Ord requires transport of the 
unit through MTMC Western Area (MTMCWA) in Oakland, CA . 
Because we are dealing with an Army unit, the Forces Command 
(FORSCOM) in Atlanta, GA also becomes a player. And, of 
course, the goal of our scenario is to show how each of 
these organizations interfaces with the Joint Deployment 
Agency and the JDS in Tampa, FI. 

Each of the above organizations uses a number of 
different automated systems for managing their assets. In 
this demonstration we will deal only with FORSCOM 's COMPASS 
which produces the Automated Unit Equipment List (AUEL) , and 
MTMC ’ s SPUR. The current procedures require the following 
steps . 
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• The unit, here 7th Infantry Division, receives a copy 
of its AUEL from the COMPASS. The Installation 
Transportation Officer (ITC) , or his staff, reviews the 
AUEL and periodically submits any updated information 
about 7th ID's equipment tc FORSCOM. 

• FCRSCOM maintains the accurate status of each unit's 
equipment. Section D of this chapter contains examples 
of the types of information maintained in the COMPASS 
data base. 

• FCRSCOM creates a tape for transfer to JDS, with the 
entire description of each unit's equipment. 

• JDA updates the Unit Movement Data (UMD) file in JDS 
from the tape transferred from FORSCOM. Section D 
contains examples of the t^pes of data in the UMD. 

• FCRSCOM creates a second tape for transfer to MTMC 
Headquarters in Washington, D.C. This tape contains 
the same basic information about unit equipment as that 
sent to JDA. 

• MTMC Headquarters manually extracts classified data 
from the COMPASS tape and forwards an edited, unclassi- 
fied version of the tape tc MTMCWA. 

• MTMCWA receives the tape from Headquarters and inputs 
the data into the System for Predetermining Unit 
Requirements (SPURs). SPURs is the on-line system that 
is used by the TOAs to schedule and manifest 7th ID on 
a particular vessel. 

• At the time 7th ID is manifested, MTMCWA must interface 
with JDS to reflect the manifest information in that 
data base. It is the JDS which will be used by all 
other participants in the successful deployment of 7th 
ID. For instance, the Military Airlift Command (MAC) 
may also provide air assets for equipment and troop 
deployment. 
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The major assumption in this process is that all three 
organizations and their associated data bases; MTMCWA in the 
SPURS, FCRSCOM in the COMPASS, and J DA in the JDS, will all 
have the exact information regarding 7th ID’s equipment and 
transportation requirements. This assumption personifies 
the major flaw in the existing system. Because of the human 
intervention required to extract classified portions of the 
data and the amount of time involved to accomplish tape to 
tape transfers, whether using AUIODIN or WIN, there are 
often significant differences in these three data bases. It 
is essential that MTMCWA, where the unit is actually mani- 
fested, has the most accurate information at all times. It 
is just as important that JDA, as the coordinator of the 
overall deployment, not limited to 7th ID, also have the 
most accurate information. 

In an attempt to stay current, the users of the SPURS 
maintain an off-line, but direct, communication with all of 
the units under its responsibility. This direct correspon- 
dence serves the purpose of data currency but tends to 
further complicate the situation. Upon receipt of unit data 
through the COMPASS to SPURs interface, the MTMCWA transpor- 
tation specialist must ascertain whether this data, or that 
which he received direct from the unit, is the correct 
information. 

C. INTERACTION DURING CRISIS DEPLOYMENT 

In the previous section we discussed the daily interac- 
tions between four particular nodes in the overall deploy- 
ment process. The procedures outlined in Section B are 
routinely accomplished without the added complications of an 
actual crisis situation. Obviously, when a crisis does 
occur, some of these procedures will be eliminated while the 
time constraint on others will be greatly accelerated. A 
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simple example of how an ac 
develop is described below. 

• First, we'll assume a cr 
where in the Pacific Th 
CINCPAC becomes both the 
commander. For the purpo 
also assume that both MAC 
responsible for troop 
However, we will discuss 
It is very important to r 
MAC would also be playi 
exchange process. 
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[Ref. 3: p. 10] 
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ations between CINCPAC, the 
pporting commanders, and the 
ult of all this effort, with 
es to the JDS data base for 
election of a specific Course 

p. 10] 



The JCS recommend this COA to the Secretary of Defense 
and the President. If the President decides to proceed 
with the COA involving military forces, the JCS issues 
an Alert Order to CINCPAC. In response to the Alert 
Order, the supporting commands and TOAs prepare an 
Operation Order. The J DA assists this process by: 



"...updating the force list and coordinating the deploy- 
ment of schedules by the transportation operating agen- 
cies. The deployment data base at the Joint Deployment 
Agency constitutes the authoritative, up-to-date source 
or force and resupply information. The data base can be 
queried by the entire deployment community using WIN." 

I Ref . 3: p- 12 ] 

• Finally, if the President decides to execute the 
planned operation, the Secretary of Defense, through 
the JCS issues an Execute Order instructing CINCPAC to 
execute his Operation Order. This begins the process 
of deployment execution. 

The execution phase of a deployment operation reguires 
constant contact and coordiration by all supporting 
commanders and TOAs, in our case FORSCOd and tlTMC. In actu- 
ality, the 7th Infantry Division would have been identified 
as a proposed supporting unit during the process of 
selecting the appropriate course of action. With even the 
possibility of using 7th ID, FORSCOM would have notified 
that commander, requested updated AtJEL information and 
forwarded the current status of 7th ID troops and equipment, 
along with their transportation requirements, to the JDS. 
All of the information must be available prior to the actual 
COA selection. 

Once 7th ID is officially notified of the order to 
deploy, the transportation process is activated. MTMCWA 
begins arrangements for ship movement of heavy equipment to 
the nearest port to the scene of the crisis. In this 
instance, 7th ID departs from Oakland, CA, the Pert of 



Embarkation (POE) and will be shipped to a Port of 
Debarkation (POD) somewhere in the Pacific. 

The actual manifest on the ship is accomplished item by 
item as the equipment and supplies are loaded. This ensures 
an accurate account of the exact load being transported. 
This exact manifest information is required for both billing 
and more importantly, for proper identification at the 
receiving POD. The manifest information is then entered 
into the JDS data base by plans personnel on site at MTMCWA 
in Oakland. It is obvious that these individuals must have 
the correct data pertaining to 7th ID's deployment to the 
POD. 

This marks the beginning of many problems which arise as 
a result of the data transfer procedures discussed in 
Section B. The exact manifest information is known, at this 
point in time, only by those individuals responsible for the 
actual manifest activity. However, when this data is loaded 
into the JDS data base, the JDS system often rejects the 
entry. In fact, whenever manifest data differs in any way 
from the plann ed equipment lead reflected in the Unit 
Movement Data (UMD) file maintained in JDS, an entry error 
is created. This data rejection causes a significant time 
lag in the effectiveness of the overall deployment process. 

D. DEMONSTRATION 

The problems arising under the current data transfer 
procedures can be significantly reduced through the applica- 
tion of the EDI concept. The use of EDI for one of the data 
transfers described in section B above is demonstrated 
below . 

Figure 4.1 is a copy of the data format for the COMPASS 
Automated Unit Equipment File (AUEL) . Figure 4.2 is a copy 
of the data format for the Unit Movement Data (UMD) file in 
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JDS. Appendix B is the EDI transaction set which would be 
used to transfer data from one system to the other. The 
data elements which are required for transfer between the 
two systems are indicated by the alphabetic characters to 
the left of the data element name in Figures 4.1 and 4.2 
The same letters (i.e., a, b, c, etc.) are used to indicate 
the same item of data within each file. It should 
be noted that the same data items are often in different 
locations and use differing field lengths in each system. 

Tracing a single data element through the transmission 
process should illustrate the cperation of the EDI method. 
Figure 4.3 contains one item of information, as shown in the 
ADEL record format and the Automated Unit Equipment listing. 
The equivalent data element in EDI format is also shown, as 
is that item positioned in the EDI transmission format. The 
JDS UMD record format for the same item is also shown. 
These have been extracted from the complete document exam- 
ples, as shown in Figure 4.1, Appendix C, Appendix E, Figure 
4.4, and Figure 4.2, respectively. 

The item labeled (a) in the record formats for AUEL and 
JDS is equivalent to one EDI element, element #111. For 
this example, it is the first element in Data Segment Dl, 
which is part of Transaction Set #365. (See Figure 3.3 for 
the relationship between elements, segments, and sets. See 
also Appendix B. ) 

The arrows in Figure 4.3 indicate the conversion flow 
for this item. Through the use of the EDI tables (see 
Figure 3.2) residing in the EEI conversion software, the 
information in positions 1-6 of field 1 in the AUEL detail 
record is put in EDI format. This element. Unit 
Identification Code (WHGHAA for this example) , which is 
mandatory, alpha/numeric, and six characters (see Figure 3.5 
for location of this information) is placed in the 
appropriate location in the data segment. Upon receipt, the 
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RFC3PD SPECIFICATION 

IDs AUEL-Decail TITLE: A DEL Cargo Detail Record 

DESCRIPTION 1 : Contains id o mac ion to identify and describe cargo shipment units 

applicable to unit moves, 

CLASSIFICATION: DECLASSIFIED LENGTH: 105 





POSITICM 


FIELD 


FIELD TITLES 


Rr? 


LGTH 


?£ti>STS 


(a) 


1-6 


1 


Unit Identification Code (ETC) 


A/N 


6 


Control Field 


(b) 


7 


2 


Type Unit .Movement Data (TTPEDATA) 


A/N 


- 1 


Control Field 




8-L3 


3 


Shipment Unit Number (SHIFTER) 


a7n 


6 


Control Field 




14 


4 


Load Number (L CATER) 

* 


A/N 


1 


Control Field 
Value is "b" 
or numeric 




15-23 


5 


Line Item Number (LIE) 


a7n 


6 






21-22 


6 


LIE Index Number (LINIKDQte) 


N 


2 




(J) 


23-43 


7 


Item Description (nomenc-Latur e) 
( ITEMS ESC ) 


A/N 


21 






44-53 


a 


Model Number (MODELER) 


a/n 


12 






56-63 


9 


Water Commocity Code (VCCMMCD) 


A/N 


5 


* 




61-62 


10 


Type Packing (TYFEPACR) 


A 


2 




(e) 


63—66 


11 


Item Length Rounded (ITDCLCTHPlfD) 


N 


4 


Rounded to 
nearest inch 


(f) 


67-70 


12 


Item Width Rounded (IT^iVDTKRED) 


N 


4 


Rounded to 
nearest inch 


(9) 


71-74 


13 


Item Height Rounded (ITMCTEFJfD) 


N 


4 


Rounded to 
nearest inch 


00 


75-81 


14 


Gross Weight Pounds (CRWTL3S ) 


N 


7 




(U 


82-38 


15 


Item Cubic Feet Rounded (ITEKCUFTEED) 


N 


7 






89 


16 


Mode to POE (MCDETOPOE) 


A 


1 




(c) 


90-92 


17 


Cargo Citegorty Code (CCCCATCLE) 


A/N 


3 




(d) 


93 


18 


Heavy Lift Code (HVTLFT) 


A/N 


1 






94-105 


20 


Filler 


A /N 


12 


. 




Figure 


4. 1 


Automated Unit Equipment 


File 


Format 
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” 1 






TRANS-UMD-DATA 


(COMPASS FILE DATA) 






01 TRANS- 


JMD-D AT A . 








02 


TRANS-UMD-HDR . 










05 


FILLER 


PIC 


X(6) . 






05 


TRANS-UMD-AREA 


PIC 


99 UALUE 


99 . 




05 


TRANS-UMO- FUNCTION 


PIC 


X . 








88 TRANS-UMD-ADD 


UALUE "ft" . 








88 TRANS-UMD-CHC 


UALUE "C". 








88 TRANS-UMD-DEL 


UALUE "D" . 






05 


TRANS-UMD-OCCURS 


PIC 


99 UALUE 


14 . 




05 


TRANS-UMD-LENC1H 


PIC 


9(4) UALUE 102. 




05 


FILLER 


PIC 


X . 






05 


TRANS-UMD-SUC-CODE 


PIC 


X . 






05 


T R ANS-UMD- P ROUORG 


PIC 


X . 






05 


TR ANS-UMD- ROUTE- LINK 


PIC 


X(6) . 






05 


TRANS-UMD-ROUTE-IND 


PIC 


X 






05 


T R ANS-UMD- ROUTE -MAP 


PIC 


X(6) 




02 


TRi 


ANS-UMD . 








(a) 


05 


TRANS-UMD-UIC 


PIC 


x (6 ) . 






05 


TRANS-UMD-MOUEMENT-GRP . 








(c) 




10 TR ANS-UMD- CARGO-CAT 


PIC 


X ( 3 ) . 




(d) 




10 trans-umd-he auy-lift 


PIC 


X . 






05 


TRANS-UMD-REC-TYPE 


PIC 


X . 






05 


FILLER 


PIC 


X ( 8 ) . 




(b) 


05 


TRANS-UMD-TYPE-DATA 


PIC 


X . 






05 


T R ANS-UMD- R EC-CLASS 


PIC 


X . 






05 


TRANS-UMD-R EC- INDICATOR 


PIC 


X . 





Figure 4.2 Joint Deployment System 0 HD File Format 
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1 





OS 


TRANS-UMD-R EC-CREATED 


PIC 


9(6) . 




OS 


TRANS-UMD-REC-LAST-CHG 


PIC 


9(6) . 


02 


TRANS-LEUEL-1 . 








OS 


TRANS-UMD-NBR-CARGO-CATS 


PIC 


9(3) . 




OS 


TRANS-UMD-TOT-STONS-BU 


PIC 


9 ( 6 ) U9 . 




OS 


TRANS-UMD-T0T-MT0NS-8U 


PIC 


9(7) . 




OS 


TRANS-UMD-TOT-STONS-OUR 


PIC 


9 ( 6 ) U9 . 




OS 


TRANS-UMD-TOT-MTONS-OUR 


PIC 


9(7) . 




OS 


TRANS-UMD-TOT-STONS-OUT 


PIC 


9 ( 6 ) U9 . 




OS 


TRANS-UMD-TOT-MTONS-OUT 


PIC 


9(7) . 




OS 


TRANS-UMD-TOT-STONS-NAT 


PIC 


9 ( 6 ) U9 . 




OS 


TRANS-UMD-TOT-MTONS-NAT 


PIC 


9(7) . 




OS 


TRANS-UMD-BULK-POL 


PIC 


9(7) . 




OS 


FILLER 


PIC 


X(2) . 


02 


TRANS-UMD-LEUEL-2 REDEFINES TRANS-UMD-LEUEL- 1 


• 






OS 


TRANS-UMD-CARGO-CAT-SUM-SQFT 


PIC 


9(6) . 




OS 


TRANS-UMD-CARCO-CAT-SUM-STONS 


PIC 


9 ( S ) U9 




OS 


TRANS-UMD-CARGO-CAT-SUM-MTONS 


PIC 


9(6) . 




OS 


FILLER 


PIC 


X(SO) . 


02 


TRANS-UMD-LEUEL-3 REDEFINES TRANS-UMD-LEUEl-1 








OS 


FILLER 


PIC 


X(14) . 




OS 


TRANS-UMD-QUANTITY 


PIC 


9(3) . 


j) 


OS 


T R ANS-UMD-C A RGO-D E SC RIP T ION 


PIC 


X( 14) . 


(e) 


OS 


TR ANS-UMD-C A RCO- LENGTH 


PIC 


9(4) . 


(f) 


OS 


TRANS-UMO-C ARGO- WIDTH 


PIC 


9(3) . 


(g) 


OS 


TR ANS-UMD-C A RGO-H EIGHT 


PIC 


9(3) . 




OS 


TR ANS-UMD-C A RGO-SQFT 


PIC 


9(4) . 


(h) 


OS 


TR ANS-UMD-C A RGO-S TONS 


PIC 


9 ( S ) U9 


(i) 


OS 


TRANS-UMD-CARGO-MTONS 


PIC 


9(6) . 




OS 


FILLER 


PIC 


X ( 2 1 ) . 



Figure 4.2 Joint Deployment System OMD File Format (cont'd) 
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r 



AUEL Record Format 




Figure 4.3 Conversion Flow of a Single Data Item 
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EDI software at the receiving site transforms this element 
{again, through the use of the tables) into JDS format, as 
determined by JDS record format requirements. It is then 
available for inclusion in JDS reports or for visual recall 
as part cf any one of a number cf information screens on the 
system terminals at JDA. 

This same conversion flow occurs for each piece of 
information which must be transmitted. It is especially 
important to note the number and size of those data items 
found in the AUEL file but not used in the UMD file. Under 
the current system this information is automatically trans- 
ferred to JDA and stripped fro it the file after receipt of 
the entire file. Using the EDI method, only those data 
elements actually used are transferred. This can be seen in 
Figure 4.4, which shows the data after it has been converted 
into EDI standard data elements and data segments for trans- 
mission. All other fields” can be transferred using one or 
more of the optional data segments, but only when deemed 
appropriate by the sender. 

Appendix C contains examples of the types of data main- 
tained in COMPASS and transferred to JDS. The data in these 
listings is currently transferred in the record format shown 
in Figure 4.1 Examination of these listings shows the 
considerable duplication of data being transmitted. The 
same essential information, in a considerably more compact 
form, is transmitted using EDI Transaction Set 365, Unit 
Movement Data (Appendix B) . This transaction set, while 
demonstrating the basic format of transaction sets, also 
lists the associated data segments which would be required 
for this specific application. Appendix A is a section of a 
Data Element Dictionary, which includes a partial list of 
the data elements used in these data segments. Comparison 
between present formats and the EDI transmission set (Figure 
4.4 shows that considerable reduction in transmitted infor- 
mation can be realized using EDI. 
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XEfNSACTICM - in 55 unit QATA 

(EG SEGMENT) 

(GS SEGMENT) 

ST-365-TRANS0001 
3GF-FI-F 1203 

NI-FW-iJSARMY FORSCCM "5 “COMPASS 

N2“US ARMY FORCES COMMAND HEADQUARTERS 

N1 •TO*' JOINT DEPLOYMENT AGENCY -6-JCS/UMO 

01- GHIJKL “0*0051 AO SN 31 9TY A UULC’FT ORO*CA~JS 

02- X60833~02*M1S1A2-975Z9-V0-U*7 

03 “TRUCK UTILITY 1/4 T0N“132*54“S3*N*24SC“L*255-E 
04“0VR*3 

02 *'1195400 —01 -M416-97SZ9-VE-U-7 

03- TRAILER CARGO 1/4 TGN-132“04-S3-N»24SO-L*2S5*E 
04*OVR“A 

02- X39940— 02-MS161 WN-975Z9“V0-U~2 

03- TRUCK CARGO 1-1/4 TON-231 -3S-72"N«7480“L“920-£ 

04- 0VR-K 

02- J96845—Q2-M167-975Z9-VE-U-1 

03- GUN AA TOWED 2CMM-lS3*78“c6“N*3260-L-467-E 

04- 0VR-9 

01- SHGHAA-R-02C9 MP CO*FT MEAOE*MO*US 

02- wgS400— 01-M416-975Z9-VE-U-3 

03- TRAILER CARGO 1/4 TCN- 1 G3 “52*44 -N*saO*L- 1 70“£ 

04 - OUR -A 

02- u95400(A )— 01 — nx-U-0 

03 - LOAD -M ISC TOE CRG ECUIP— S00-U-3Q-E 

02- X40009— 02*M25A2-975Z3-v0-tj-1 

03- TRUCK CARGO 2-1/2 T0M-265“95“98-N“l3180-L-1292-“ 

04- tDUR-S 

02- X40009(A)— 02 — nx-u-i 

03- L0A0-MISC TOE ORG EQUIP— 4820-L-270“E 

02- X40146— 02-M25A2 WWN-37SZ9-V0-U-1 

03- TRUCK CARGO 2-1/2 T0N-279-95-93-N-13S70-L-1259-E 

04- OVR-S 

02-X401 46(A)— 02— MX-U-1 

03“U0A0-f1ISC TOE ORG EQUIP— 4820-L-270-E 

02- U9S8 1 1 — 02-M 105A2-975Z9-VE-U-2 

03- TRAILER CARGO 1-1/2 T-166“93*92-N*2570“L-554-f 

04- CUR-3 

02- U9S31 1 (A)— 02— -MX-U-2 

03- LCAO-MlSC TOE ORG EQUIP- 293Q-L*200-E 



K4-CCMMENTS 

SE-23-TRANS0C01 



(GE SEGMENT) 
(EG SEGMENT) 



Figure 4.4 



Transmission of Data Set #365 in EDI Format 



E. 



EDI ADVANTAGES 



The data elements, segments, and sets utilized in the 
EDI concept are designed to be applicable to a wide variety 
of applications. Through the use of the table-driven 
system, command unique forms can be translated into generic 
data elements, and combined into transaction sets which can 
be transmitted to many other organizations. Because the 
receiving organizations’ EDI software will translate the 
transmitted elements into locally desired formats, the same 
transmission could actually result in reports in vastly 
different formats at multiple locations. This highlights 
one of the major benefits of the EDI procedures: standard 
formats are not required for effective community-wide data 
transfers. 

As shown above, the problems arising under the current 
data transfer procedures are primarily the result of ineffi- 
cient use of existing communica tions assets. As previously 
discussed the current system requires transfer of the entire 
COMPASS file, including data elements not required for use 
in JDS. This file is then interpreted at JDA, the necessary 
data is extracted from the COMPASS file and inserted in the 
proper format into the UMD file in the JDS data base. The 
actual file transfer is accomplished as a tape-to-tape 
transfer using the File Transfer Service (FTS) of the FIN. 

The basic nature of a tape-to-tape transfer automati- 
cally makes this a relatively slow, inefficient process. In 
a rather volatile network, subject to frequent, if minor, 
interruptions in communications service, this often necessi- 
tates numerous retransfers of previously delivered data in 
an effort to ensure accuracy of the total file. In this 
demonstration, we propose a disk-to-disk transfer in order 
to eliminate the need to retransmit the entire file if the 
transfer is interrupted by a communications break. This 
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alone will signif icantly reduce the time lag between the 
locations involved, and thus increase the probability that 
the data will agree at both sites. 

An even more effective difference between the current 
transfer method and the EDI method demonstrated here is in 
the vastly reduced amount of data reguired to be sent. Ihe 
EDI method, as shown in Figure 4.4, requires that only those 
data elements actually used at the receiving site be trans- 
ferred. The determination ox reguired elements is made 
through the table-driven operations. Data elements not 
reguired are listed as optional in the data segments. In 
fact, in some cases the data segments are optional, 
depending upon to which site(s) the transaction set is 
transferred. By eliminating unnecessary data from the 
transaction set, the sender can ensure the most efficient 
use of the computer systems and the communicati ons network. 
In this example, a reduction of approximately 50% in trans- 
mitted data would be realized. 

F. SUMMARY 

Within the joint deployment community, extensive data 
transfers are necessary for planning and execution of 
deployment efforts. In a scenario involving MTMCWA, 7th 
Infantry Division, FORSCOM, and JDA , data transfers such as 
the one demonstrated would be reguired. The current trans- 
fers utilize tape-to-tape transfers and transmit entire 
reports, including redundant information, and information 
utilized at the originating end but not the receiving end. 
Data transfers to satisfy the same scenario reguiremen ts, 
but utilizing the EDI method, provide several benefits. 
Conversion to multiple formats for multiple receivers is not 
necessary. Disk-to-disk transfers reduce the necessity for 
retransmission in case of interrupted transmission. 



Additionally, the 
decreases the burden 



reduced amount of data 
cn communications assets. 



transmitted 
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V. INTERFACE A EP LOCATIONS 



A. INTRODUCTION 

The previous chapters have established the necessity for 
an efficient electronic data interchange, and have demon- 
strated the technical feasibility of the EDI concept as just 
such an exchange. 



Deployment management systems (personnel, hardware, 
communications equipment, software, procedures) must 
collectively support the deployment process from the 
National Command Authorities ‘(NCA) level to the instal- 
lation level using fully integrated concepts which 
maximize our deployment capabilities and provide neces- 
sary surge capacity to meet time-sensitive crisis and 
wartime requirements. [Ref. 11: p. 14] 



Joint planning experiences and exercises have shown the need 
for better coordination and understanding of the myriad 
mobilization and deployment infcrmation systems which either 
currently exist or have been conceptually determined. 
[Ref. 2] A brief discussion of some of these systems should 
highlight potential applications of an interchange such as 
the EDI concept. 



B. INTEGRATED NETWORKS 
1 . TC ACCIS 

One significant advancement toward the implementa- 
tion of an automated interface is the development of the 
Transportation Coordinator Automated Command and Control 
Information System (TC ACCIS) prototype. TC ACCIS is a 
response to lessons learned during JDA directed exercises 
regarding our ability to deploy forces and sustain materiel 
and personnel under crisis conditions. The JDA is the Joint 
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Project Manager of this development effort which is being 
conducted within the WWMCCS Research and Development 
program. The TC ACCIS effort will provide an automated unit 
movements data base at the unit and shipper level, an auto- 
mated surge capability to the installation transportation 
coordinator, and an automated interface between the 
Installation Transportation Office (ITO) and the associated 
TOA. 

2 • TC PIS 

A planned enhancement to the TC ACCIS prototype, 
called the Transportation Coordinator and Deployment 
Information System (TC DIS) , includes an interface with 
major commands in an effort to give them improved visibility 
over the deployment status of units assigned to them and 
provides them a capability to influence the situation. In 
addition, TC DIS provides an interface directly from the 
unit, where it is generally agreed the most current informa- 
tion is of necessity available, to the JDS. 

The TC DIS concept recognizes multicoamand , multi- 
functional interfaces during the deployment management 
process. Service and command systems which already exist 
can be complemented by automation through electronic inter- 
faces. Existing systems are generally stand-alone func- 
tional systems. Some use notional data as their basis for 
initial planning. Aging can occur because data maintainers 
do not always have ready access to the systems for updating. 
[Ref. 11 : p. 32] 

C. SERVICE SYSTEMS 

Service systems which were created at the MAJCOM level 
include DEMSTAT, COMPASS, and COKPES. Existing systems at 
the TOA level which provide networks for reporting vital 
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movement information from support elements at installations 
and POEs to the TOAs include SEMS, SPUR, ASPUR, TOLS, ME IS, 
and HAIRS. Many of the systems which exist at the MAJCOM 
level are also located at the installation level. These 
systems usually have existing interfaces within the overall 
system between levels, and could potentially be connected 
under the TC DIS concept. Additionally, there are systems 
still in development phases which will provide enhancements 
to the automation of the deployment community information 
requirements. 

1 . MAJ COM Lev el Sys te ms 
a. DEMSTAT/COMPASS 



The Deployment, Employment, Mobilization Status 
System (DEMSTAT) was developed to provide Forces Command 
(FORSCOM) with a system which would place in execution those 
plans developed in planning systems such as JDPS. It is 
activated during crisis situations, and combines several 
automated planning systems utilizing ADP resources of 
WWMCCS. This system is used to identify units for specific 
operations and to manage those forces during the execution 
of the operation. When activated, the DEMSTAT database is 
the "sole source for execution of all mobilization/ 
deployment/employment operations and the operation’s associ- 
ated requirements." [fief. 2: p. 34] The database is updated 
by automated reports from FORSCCM itself, from J DA , and from 
reporting commands/installations. [Ref. 2: p. 35] 

The DEMSTAT system is the execution system which 
is used in conjunction with the planning system COMPASS. 
The primary objective of COMPASS is to provide an automated 
system with unit movement information used in mobilization 
and deployment planning. Information in COMPASS is used to 
create the AUEL which provides the unit movement 
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requirements information to MTMC. These two systems have no 
real automated interface, although the information in 
COMPASS is used in DEMSTAT. There is presently an interface 
between DEMSTAT and JDS, where information is transferred 
through an existing automated interchange via AUTODIN, 
although the WIN is not used. DEMSTAT uses fewer fields 
than JDS, and so when the transfers occur, the fields appro- 
priate to DEMSTAT are stripped from the information trans- 
ferred by JDS. This interface is representative of the 
command to command interface as discussed in Chapter II. 

b. COMPES 

The Contingency Operation/Mobility Planning and 
Execution System (COMPES), an Air Force standard system, is 
comprised of three modules: an Operation Plan Module, a 

Logistics Module, and a Manpo ver/Personnel Module. This 
system is implemented at both the MAJCOM and base levels 
throughout the Air Force. Its functions include logistics 
planning applications and monitcring the status of deployed 
units. The Logistics Module in particular was designed to 
satisfy the needs of both base-level and MAJCOM logistics 
planners responsible for deployment planning. COMPES* 
primary benefit is to provide “...a standard Air Force 
deployment planning system which will minimize training 
requirements, and provide a standard reference system for 
inter command deployment planning." [Ref. 2: p. 23] There 

are existing interfaces between COMPES at the MAJCOM level 
and the base level. There are also interfaces between 
COMPES and JOPS and UNITREP. Those interfaces currently 
involve data transfer via AUTODIN using tape to tape dump. 
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2. Installa tion /TO A level Syst em s 



a. SEMS 

The Marine Corps’ Standard 
Management System (SEMS) provides deployment pi 
mentation and execution planning assistance fo 
operations worldwide. The information in SEMS i 
personnel, supply, and equipment information at 
and battalion level. Standalone deployable m 
are used, with diskettes which can be processed 
Marine Force (ADPE-FMF) IBM 4 110 computer. T 
current interfaces with other deployment systems 
the SEMS is precisely the type cf system which w 
from an EDI interchange as postulated in the TC 
[Ref. 2: p. 74] 

b. SPUR/ASP DR 

The System for Predetermining Unit 
(SPUR) is "an initial step towards documentation 
tion aimed specifically at unit deployments 
locations under emergency conditions." [Ref. 2 
SPUR obtains much of its data from the AUEL 
COMPASS. The information is stored either in m 
files or disk packs. Objectives of SPUR include 

Eliminate ITO of detailed Routing Requests at 

Eliminate unit submission of Advanced Tran 
Control Movement Document ( ATCMDs) at deployine 

Reduce the MILSTAMP document work load at e 
terminals by preplacement of ATCMDs in the 
base. 

Provide area commands with an automated dat 
unit leading information collected in advance. 

P- 77] 



Embarkation 
anning docu- 
r amphibious 
ncludes unit 
the squadron 
inicomputers 
on the Fleet 
here are no 
. However, 
ould benefit 
DIS concept. 



Requirements 
simplifica- 
to overseas 
p. 77]. 
generated by 
agnetic tape 



deployment 

sporta tion 
nt time 

mbarkat ion 
TERMS data 



a base of 
[Ref. 2: 
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There are no current interfaces with other 
systems. However, SPUE is the foundation for an automated 
system which is scheduled to become operational in May 1985. 
This system {Automated Systems for Processing Unit 
Eeguirements - ASPUE) will continue to provide the capa- 
bility to receive and process reguirements from the AUEL. 
One of its proposed primary functions is to receive, 
process, and store movement reguirements from TC ACCIS as 
well as other sources such as METS, TOLS, and JDS. These 
data transfers will be accomplished by using a high speed 
central processor. [Ref. 2: pp. 11-12] 

c. MAIRS 



The Military Air Integrated Reporting System 
(MAIRS) provides automated support for the Military Airlift 
Command (MAC). It provides information such as aircraft 

movement and delays, passenger and cargo reguirement 
summaries, and movement data to MAC, MAC Numbered Air 
Forces, and the JCS. There is currently an interface with 
AIMS, another Air Force automated system. There are no 
interfaces with other TOA or deployment related systems, 
although the potential exists for interface with the JDS. A 
test MAIRS— JDS interface has been proposed, which will 
forward airlift arrival/departure information to JDS. This 
interface will utilize AUTODIN. [Ref. 2: pp. 53-54] 

D. SUMMARY 

Systems which represent significant advancement in the 
automated interface arena are the TC ACCIS and the TC DIS. 
The TC DIS is an enhancement to the TC ACCIS , and will 
provide a direct interface between the unit and JDS. There 
are a variety of automated systems throughout the joint 
deployment community, with a wide range of existing 
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interface capabilities. The potential exists within most of 
these systems for increased interfaces, as indicated in 
Figure 2.3. The EDI method of interfacing is ideal for many 
of these applications. Since each of the systems described 
above was designed and developed by individuals for the 
separate services, some of the data descriptions and formats 
may differ according to the given service requirements. The 
EDI concept is designed precisely to address these types of 
issues; therefore, this interchange concept would be appro- 
priate for interfacing systems throughout the community. 
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VI. IMPLEMENTATION CONS ID E EATIO NS^R ECOMMEND ATIONS 



A. INTRCDOCTION 

In order to effectively implement any interface system, 
the coordination and cooperation of all involved services or 
agencies is essential. For the purpose of this discussion 
those involved agencies, termed the Joint Deployment 
Community (JDC) , are collectively referred to as 



Those headquarters, command, and agencies involved in 
the training, preparation, movement, reception, employ- 
ment, support, and sustainment of military forces 
assigned or committed to a theater of operations or 
objective area. The JDC usually consists of the OJCS, 
Services, certain service major commands {including the 
Service wholesale logistic commands) , unified and speci- 
fied commands (and their service component commands) , 
DLA, the TOAs, JDA, joint task forces (as applicable), 
and other defense agencies (e.g., DIA) as may be appro- 
priate to a given scenario. [fief. 5: p. x] 



It is immediately apparent that when such a large group of 
diverse organizations must agree on any concept of opera- 
tions, problems are bound to arise. Therein lies a major 
obstacle to the acceptance cf this proposed interface 
system. 



B. JOINT DEPLOYMENT COMMUNITY REACTIONS 

There is almost unanimous agreement throughout the JDC 
that the need exists for an automated interface between the 
units, the TOAs, and JDA. Additionally, virtually all agree 
that state of the art technolcgy is readily available to 
accomplish the necessary hardware and software connectivity. 
However, there is widespread disagreement among the various 
participants regarding the required level of interface, the 
necessary detail of data exchange, and which particular 
technical solution to implement. 
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Analysis of the JDC responses to the proposed TC ACCIS 
and TC DIS reveals a wide disparity of opinions about the 
feasibility of both TC ACCIS and the expanded capabilities 
of TC DIS. Although many representatives throughout the 
community favor the overall concept of TC ACCIS, there are 
just as many who disagree with large portions of the plan. 
Even among its supporters, there are overriding concerns 
about the ability of the community as a whole to make the 
system work. Some cf the more frequently raised objections 
are described below. 

1 • iTO^JD S In t er fa ce Ne ce ssity 

A primary concern is whether or not there is truly a 
need for direct interface between the automated unit data 
base and the JDS. Such an interface is proposed in the TC 
DIS ROC as a one-way link with the JDS having access to unit 
data but the unit having no need for access to the JDS data 
base. This is obviously for security purposes, to protect 
the classified data maintained within JDS. There are a 
number of objections to this interface: 

• One of the basic premises in the TC DIS ROC is that the 
transfer of unclassified unit information from the 
installation data base would be in an unclassified 
mode. The assumption that ail unit data is unclassi- 
fied is not necessarily valid. Certain information 
about individual units vhen combined within a partic- 
ular installation’ s data base becomes more sensitive. 

• In a crisis situation, the supported CINCs obtain 

necessary information about the current deployment 
status of required forces and material through the JDS. 
Much of this information is already available to JDS in 
other existing systems. The remainder of the required 
information could be obtained by JDS from the TOA. 
This is especially true if the proposed 

ins ta 11a ti on/TO A interface can be developed. 



• There is significant disagreement concerning the level 
of detailed data actually reguired within the JDS. The 
services tend to believe that allowing the JDS a direct 
interface with the units would increase a perceived 
tendency on the part of JDA to micro-manage every 
aspect of deployment. 

• There is a major 'turf tattle' ensuing between the 
services and the JDA. The services feel that the JDA 
has more than overstepped its bounds by even indicating 
that subordinate organizations should report directly 
to them without following through normal command chan- 
nels. None of the services are willing to give up 
control of their own forces to this extent. 

2 • System C om pa tibility 

Concern has also been expressed that any new system 
development must be made compatible with existing service 
unigue systems. There is a feeling among the community that 
some aspects of TC ACCIS are not adequately considering this 
compatibility. Additionally, the Joint Reporting Structure 
(JRS) requirements must be carefully considered to enhance 
unit reporting and to modernize the JRS. A primary thought 
here is that TC ACCIS implementation should be carefully 
monitored to ensure that nc additional reporting is 
required. 



3. Communicatio ns Capacity 

Any new interfaces, regardless of the level, would 
be heavily dependent on the WWMCCS Intercomputer Network 
(WIN) for the communications transfer of the actual data. 
The WIN is already severely taxed to satisfy current 
operational requirements. Some of the members of the commu- 
nity feel that added interface requirements might over 
encumber existing WWMCCS facilities. 
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4 . 



Sec ur ity 

As already alluded to, there is the significant 
problem of data classificat ion and the security of classi- 
fied information. It is inevitable that even unclassified 
data at unit level will ultimately be classified at some 
higher level as it is incorporated into the JDS. The JDS 
data base is TOP SECRET. There are many guestions regarding 
the ability to adequately protect potentially classified 
data in an interface between remotely located computer 
systems. 

5 . Mode rni zat ion E ffor ts 

Finally, all participants in the JDC have expressed 
interest in the evolution of both the JOPES and the VIS. It 
is imperative that these proposed interfaces be developed in 
conjunction with the OTMCCS standard JOPES and PJIS efforts. 

C. EDI IBPLEHENTATICN LIHITATICNS AND DIS ADVANT AG ES 

Some of the above issues suggest limitations or disad- 
vantages to implementation of the EDI concept. Some of 
these are actually 'political' problems as opposed to tech- 
nical problems, and as such are beyond the scope of this 
thesis. 

Security issues are a combination of political and tech- 
nical problems. The EDI interface software, consisting of 
the data elements, segments and sets and the associated 
tables, do not inherently possess security restrictions. It 
is assumed that the security issues will be handled by the 
command's existing computer hardware and software. 
Determination of access reguirenents/allowances must be made 
prior to concept implementation; the potential exists for 
concept limitations based on security requirements. 
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The disadvantages associated with implementation of an 
interface utilizing the EDI concept are primarily initial 
disadvantages. The most significant effort required would 
he the programming needed. Each command utilizing the 
concept will need a program which provides the interface 
between their current system and the EDI software. While 
this effort is substantial, it is for the most part a one- 
time operation. Once the program is running, modifications 
to incorporate command changes are minor. 

Associated with this interface software is also the 
computer time and space required for its operation. While 
this differs from system to system and is thus hard to quan- 
tify in a general sense, it dees reduce computer capacity 
available for intr a-ccmraand operations. 

Another ’cost’ incurred when implementing the EDI 
concept is the community wide requirement to identify data 
sets, segments, and elements necessary for the interface. 
The majority of these items are in existence, as those 
developed by TDCC are designed to be applicable to a variety 
of industries. In some cases, additional codes may be 
required to enable the use of existing data elements. There 
would probably be more new sets and segments required for 
application to the joint deployment community. It will 
require high level support of the EDI concept to ensure 
timely agreement among the users on the exact makeup of the 
new sets and segments. In order to assist in both the 
creation of these items and the software design described 
above, TDCC offers two-day sessions intended to provide 
selected individuals the necessary training and information. 

Although this training is available, the assistance of a 
civilian company in the software design will likely be 
required. There are several companies, primarily in the 
Washington D.C. area, which can provide this service. Their 
names may be obtained from the TDCC. The cost for such 
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upon the extent of 



assistance would be completely dependent 
assistance required. 

One potential political obstacle to the im 
of the EDI concept is the community-wide accept 
concept as the appropriate alternative. The 
support and commitment required does not pres 
However, the need for improvement in the communi 
become more apparent, and support for community 
face is growing, as evidenced by the money 
invested in the TC ACCIS and TC DIS programs. 

D. BENEFITS OF EDI 

We fully accept that all of these concerns a 
we realize that many of the issues must be res 
any effort is made toward implementing the syste 
proposed by TC ACCIS and by this thesis. Some 
tions raised are more within the political realm 
solved by careful coordination with the agencie 
zations involved. Those types of issues ar 
addressed here. 

However, many of the supposed ’problems’ w 
problems at all if the EDI standard interface 
demonstrated in this thesis, was adopted as t 
solution to the actual data exchange portion of 
and TC DIS. 

One of the major issues is the current requ 
existing service unique systems would have to 
to be compatible with the JDS data element s 
order to effectively accomplish any interface, 
proposed EDI system, there would be no ne 
interface data bases to be maintained in ident 
All existing and potential systems could 
according to individual service requirements. 



plementation 
ance of this 
high level 
ently exist, 
ty today has 
-wide inter- 
and effort 



re valid and 
oived before 
m interfaces 
of the ques- 
and must be 
s or organi- 
e not being 

ould net be 
system, as 
he technical 
the TC ACCIS 

irement that 
be converted 
tructure in 
Using the 
ed for the 
ical format, 
be designed 
The EDI 
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interface programs automatically perform the conversions 
necessary to allow each system to interface with the stan- 
dard data elements. This provides automatic interfacing 
between each system and JDS. An added benefit of the EDI 
conversion technique is that any system can also interface 
with any other system using the same conversion program. 
Thus it is easily possible for the three TOAs to have inter- 
faces with each other as well as the proposed interface 
between the TOAs and JDS. 

There would be seme effort required initially to develop 
standard data sets for transfers unique to military require- 
ments. However, the advantages of using EDI far outweigh 
the time and manpower required to establish these standard 
data sets. First, once the standard data sets are deter- 
mined, new systems can be added and easily interfaced with 
the addition of only one new conversion program. 

Second, the process of converting data files into the 
standard data sets automatically eliminates all but the 
essential information which must be transmitted. This would 
significantly reduce the amount of extraneous data being 
sent over already overloaded communications systems. In 
fact, use of the standard data sets should minimize use of 
the KIN, thus allowing it to be available for more interac- 
tive applications. 

Finally, and most notably, the adoption of the EDI 
interface by the JDC would improve the overall effectiveness 
of the joint deployment process. Providing an automated 
interface enabling direct connection between all the partic- 
ipating agencies would ensure that the individual data bases 
at each agency are as much as possible in agreement with 
other agencies involved. Thus when an actual deployment 
must take place, all concerned parties will have ready 
access to current data which they require to accomplish 
their given mission. 
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E. 



SUMMARY 



The necessity for continuous interaction between members 
of the joint deployment community is obvious. Current 
systems and interfaces are not providing the efficient and 
accurate data transfers required. Standardization is the 
solution most commonly proposed to alleviate the current 
situation. This proposal, however, has drawbacks which have 
been previously discussed. 

The EDI concept - a table-driven electronic interface 
utilizing data elements, segments, and sets - is a proposed 
interface which would provide the necessary data transfer 
capabilities throughout the community. While there are many 
concerns about implementing this system, most of them are in 
the political realm, and are beyond the scope of this 
thesis. The technical feasibility of the EDI concept has 
been proven in use in several industries over the past few 
years. The application of this system to the military has 
been demonstrated in this thesis. Implementation within the 
joint deployment community wculd alleviate many of the 
current inadequacies and provide an advanced, efficient 
means of data transfer which would contribute to the profes- 
sional performance of the joint deployment community. 
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APPENDIX A 

DATA ELEMENT DICTIONARY 



This appendix is a partial EDI Data Element Dictionary. 
The elements included here are used in the transaction set 
shown in Appendix B. These elements correspond to the data 
fields in a user site’s data base. 



19 CITY NAME 

(Spec: Type = AN Min = 2; Max = 19} 

Free-form text for city name 

Reference Designator (s) : D40 1 D701 D906 E401 

E701 F 40 1 F701 F906 

G40 1 H502 L715 N401 

NAM05 ET203 RT205 RIN04 
S402 S903 T209 T210 

Tb04 T607 2T03 U401 

U901 V905 N304 W404 

Y 106 



22 COMMODITY CODE 

(Spec: Type = AN Min = 1; Max = 10) 

Alpha/numeric code used tc describe a commodity or 
group of commodities for rating and billing purposes. 
Also see: COMMODITY CODE QUALIFIER (23) 

Reference Designator (s) : AC05 E607 GA07 L503 

PRO 3 PR 04 1R03 1R04 

1R05 1 R 06 1R07 TD104 

TF301 TF302 9T02 W203 

KOI 11 W0411 



23 COMMODITY CODE QUALIFIER 

(Spec: Type = A Min = 1; Max = 1) 

Qualifier for the commodity coding system used to 
define the item lading description (See Appendix A- 
A6 thru A13, A33) 

CODE DEFINITION 

A SCHEDULE A, tariff schedules of the 

United States annotated 

B U. S. foreign trade SCHEDULE B, statistical 

classificat ion of domestic and foreign 
commodities exported form the United States 
C Canadian freight classification 

E coordinated motor freight classification 

G Canadian wheat board, grain code for 

terminal elevator accounting 
H Brussels nomenclature harmonized system 

(harmonized BTN) 

I MUST AMP 
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L last contained contents STCC 

M mutually defined 

N national motor freight classification (NMFC) 

S standard international trade classification 

(SI 1C) 

T standard transportation commodity code (STCC) 

U uniform freight classification (UFC) 

Also see: COMMODITY CODE (22) 

Reference Designator (s) : GA01 L504 1R02 TD103 

ST 03 HOI 10 F04 10 



26 COUNTRY CODE 

(Spec: Type = A Min = 2; Max = 2) 

Two character xSC standard country code 
(See Appendix A-A5) 

Reference Designator (s) : 1404 D704 D904 E404 

ER001 F40 4 F704 FS04 

E404 NAM 09 R405 R6 10 
S405 S905 U404 US04 

V907 X 1 0 7k 



65 HEIGHT 

(Spec: Type = D2 Min = 1: Max = 6) 

Vertical dimension of an olject measured when the 
object is in the upright position. 

Also see: LENGTH 732f 

MEASUREMENT UNIT QUALIFIER (90) 

WIDTH (189) 

UNIT OF MEASUREMENT CODE (355) 
Reference Designator (s) : G3907 L403 P0415 



66 IDENTIFICATION CODE QUALIFIER 

(Spec: Type =AN Min = 1; Max = 2) 

Type of identification code: 

CODE DEFINITION 

1 DUNS 

2 SCAC 

3 FMC 

4 IATA 

5 SIRET 

6 Mutually defined 

7 DOCK 

8 Vendor UPC code 

9 DUNS with 4 digit suffix (UCS uses 

only CCDE 9 f 

A Automotive Industry Action Group(AIAG) 

Reference Designator (s) : 51101 A1203 A1205 C105 

C202 C40 1 D102 D503 

El 02 F 1 0 2 F503 F0108 

F0806 F0911 N 10 3 Q407 

SI 03 S80 9 U 102 U502 



67 IDENTIFICATION CODE 

(Spec: Type =AN Min = 2; Max =17) 

DUNS, SCAC, FMC, SIRET, IATA, UPC, DUNS with 
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suffix, mutually defined or DOCK code (See 
Appendix A-A2, A16, A17, A 18) 

Note: UCS uses only DUNS with suffix. 

Also see: IDENTIFICATION CODE QUALIFIER (66) 

Reference Designator (s) : 



A1 


102 


A 1 2 04 


A 12 06 


CIO 


6 


C2 


03 


C4 02 


D 103 


D50 


4 


11 


03 


F 103 


F504 


F 0 1 


09 


P0602 


F0603 


F0807 


F0 9 


12 


R 1 


04 


Q408 


S 1 04 


S81 


0 


Cl 


03 


0503 









81 WEIGHT 

(Spec: Type =H Min = 1 ; Max = 8) 

Numeric Value of Weight 
Also see: WEIGHT QUALIFIER (187) 

WEIGHT UNIT QUALIFIER (188 
UNIT OF MEASUREMENT CODE ( 

Reference Designator (s) : CTT03 F0401 

G0503 G2004 
G7603 GD105 
1301 L80 3 

N703 Q20 7 

TD305 W 0 2 0 6 
VI 2 10 1-71213 
W 2 1 0 9 W2507 
V 7602 
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F0404 
G3103 
ISS03 
M 303 
Q402 
W 0 2 0 9 
H2004 
W2510 



G505 
G3901 
LOO 4 
Ml 105 
TD 107 
W 0 3 0 2 
W2106 
W2802 



82 LENGTH 

(Spec: Type =D2 Min = 1; Max =6) 

Largest Horizontal Dimension of an Object 
measured when the object is in the upright 
position. 

Also see: HEIGHT (65) 

MEASUREMENT UNIT QUALIFIER (90) 
WIDTH (189) 

UNIT OF MEASUREMENT CODE (355) 
Reference Designator (s) : G3909 L401 P0413 



93 NAME 

(Spec: Type =AN Min = 1; Max = 35) 

Free-form organization name or official title 
as it should appear for mailing address 



Reference 



Designator (s) : 



G303 Go 1 02 N 102 N201 

N202 NAM 02 S808 SCH 05 
2T01 l J 6 1 0 2 
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APPEND 21 B 

TEANSACTIG N SET #365 



This appendix contains the transaction set, shown as it 
would be in the EDI Data Set documentation. This trans- 
action set is required for the data transmission described 
in Chapter IV. 



365 UNIT MOVEMENT DATA 

ABSTRACT: This transaction set is used by the sender to transmit 

unit movement data to other joint deployment community members. 

Require- n» loop loop 
nent Use ID lncer 

ST TRANSACTION SET HEADER 

PURPOSE: To indicate the start of a transaction set and to 

assign a control number 





1 


1 ST01 143 1 


1 ST02 


329 1 


1 




M 1 0 0 


1 ST 


1 

> * 


1 Transaction 1 
1 Set ID 1 * 


1 Transaction 1 
1 Set Control 1 


rj 


"AOI” is a 


special process used 




1 


| - A01 | 


I Number i 


in tne EDI 


interface software to 




1 


1 n AN 03/03 1 


1 n an 


04/09 1 


i 


process the set ID, version, & 



1 1 1 1 1 1 functional 10. 

17 Characters maximum length 



BGF BEGINNING SEGMENT FOR FILE TRANSFER INFORMATION 

PURPOSE: To transmit identifying numbers, dates, and other 

basic data relating to the transaction set. 



1 \ 

| | 


‘ BGF 01 128 1 

l i 


1 BGF02 127 1 
1 1 




1 

1 


M 


1 0 0 


BGF| - 


1 1 
1 Reference 1 


1 | 
Reference i 


N 


1 

1 






1 1 


iNo. Qual | 


Number 
1 1 


L 


1 






1 1 


| M AN 02/02 | 


| (1 AN 01/22 | 




1 







31 Characters maximum length 



7 1 



365 UNIT MOVEMENT DATA 



Beouire- flax Loop Loop 

npnt Us? 10 Index 



N1 NAME 

PURPOSE: To identify a party by type of organization, name and code 



1 1 
1 1 


1 N1 0 1 98 1 

I 1 


1 N1 02 93 1 


1 

| 


M 2 0 0 


I N V 


1 1 
.Organization " 


1 1 
1 Name | 


1 

* 

1 




1 1 


1 Identifier | 


1 1 


1 


The type of organization to which 


1 1 


| H AN 01/22 1 


| C AN D1/3S | 


1 


the name is applied is specified 










Dy a two character code. The 
definition for data element 93 
contains the code list. 


1 

1 


1 N1 03 66 1 

l i 


'N104 67 1 

1 | 


1 

1 


1 

* 

1 


1 I 

1 ID Code | * 
. Qualifier 


I i 

1 ID Code | 
P0304 


N 

1 . 


Uhen N103-N104 are not used, 
Nl 02 (name) is required. 





1 


P0304 1 


1 


1 - 






1 C 


AN 01/02 1 


1 c 


AN 02/17 | 





63 Characters maximum length 



N2 ADDITIONAL NAME INFORMATION 
PURPOSE: To specify additional names or those longer than 35 
characters in length 



1 1 

1 i 


1 N20 1 93 1 


1 N202 
1 


93' 


I 


0 2 0 0 


1 1 
1 N2 | 

1 1 


Name 

1 1 


Name 

1 I 




This is a required seonent if 
additional infornation is 
required to conpletely specify 


1 1 


| h AN 01/35 1 


1 0 AN 


01/35 1 


_J 


the nane. 



75 Characters maximum length 



NOTE: NT and N2 are required for the sending organization 
and for the receiving organization. 
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365 UNIT MOVEMENT DATA 



fieauire- Rax loop loop 

nent Use ID Index 



D1 UNIT IDENTIFICATION 

PURPOSE: To specify unit identification code (UIC) 
and additional unit information 



D1 



D1 01 111 

UIC 

(1 AN 06/06 



D102 146 

Type 

UMD 

ft AN 01/01 



D103 93 

Name 

0 AN 01/35 



D 1 04 19 

City 

Name 

(Station) 

0 AN 02/19 



D105 156 

State 

c A 02/02 



□106 26 

Country 

Cede 

C A 02/02 



N 

L 



M 1 0 0 



Uhen OlOd not 
used, 0105-0106 
not used 



65 characters maximum length 



D2 EQUIPMENT DETAILS 

PURPOSE: To provide equipment information 



i r 


1 D201 122 


1 D202 324 


1 D203 532 




i i 
1 D2 


Line 

M 


- Load 


Line 

« 


« 


1 Item 


1 Number 


1 Index 




1 1 


1 Number 


1 


1 Number 




1 L 


| M AN 06/06 


| 0 AN 01/01 


| M N 02/02 





Note: Mandatory when 



1 D204 


24 1 


1 D205 64 1 


' D2D6 21 6 1 


1 cooe in segment NIDI 


Model 


1 Water ^ ^ 

1 Commodity 1 

1 Code 1 


1 1 
| Type | - 


1 is JD (=Joint 
Deployment Aqency); 


Number 


Packing 


optional otheruise 

| 


| 0 AN 


01/12 | 


| 0 AN 05/05 | 


| 0 A 02/02 | 


i 
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365 UNIT MOVEMENT DATA 



Require- Rax Loop Loop 

npnt Use ID Index 



1 D2D7 9T 1 1 

l In' 

I Mode | | 

I I L I 

I n a 01/01 | | 

29 characters maximum length 



D3 EQUIPMENT MEASUREMENT 

PURPOSE: To describe physical dimensions 



D3 



D301 372 

Item 

Description 
11 an 01/02 



D302 82 



Length 



C N 01/06 



D3C3 189 



Width 



C D2 01/06 



D304 65 

Height 
c 02 01/06 



D307 188 

Weight 

Unit 

Qualifier 
n a 01/01 



1 D305 90 

» 

Measurement 
Unit 

Qualifier 
c a 01/01 



D30b 81 
Weight 

n N 01/09 



□308 183 

Volume 
n n 01/00 



D309 184 

Volume 

Unit 

Qualifier 
n a 01/01 



N 

L 



C 1000 0 0 



Note: Trus data 
segrent required if 
cooe in segnent N101 
is JD; optional 
otherwise 



58 characters maximum length 



74 



365 UNIT MOVEMENT DATA 



D4 CARGO INFORMATION 

PURPOSE: To provide cargo information 



Require- flax Loop Loop 

nent Use 10 Index 



“T 

i 


1 D401 


413 1 

i 


T D402 414 1 1 

1 1 1 


C 1 0 C 


04 


« Cargo 

' Category ' 


Heavy N 

1 Lift 1 L 1 


Note: This data segnent is required 

if code in segnent N101 is JD 


1 


1 Code 1 


1 Code 1 1 


(=Joint Deplovnent Agency); 


L 


1 M 


AN 03/03) 


1 M AN 01/01 1 1 


optional for others 



04 characters maximum length 



K4 COMMENTS 

PURPOSE: To transmit information in a free-form 





format, if necessary. 


for comment or special 


instruction 


1 1 K4D1 


633 1 1 


C 


1 0 0 



1 K4 


i 

1 Comments 


N 

L 




1 

1 n AN 01/00 


1 1 
1 1 



84 characters maximum length 



SE TRANSACTION SET TRAILER 



PURPOSE: To indicate the end of the transaction set and provide 

the count of the transmitted segments (including the 

segment) 

C 1 0 0 

The control nunher is the sane as that 
used m the corresponding header. 

Note- "A16" and "A17" are 
process identifiers in tne EDI edit 
taoles which are used to construct or 
check the data elements in the "SE" 
segnent. 

04 characters maximum length 



beginning and ending (SE) 





1 


1 SE01 


96 1 


'SE02 


329 1 




1 SE 


1 

. * 


1 Number of 1 
. * 


Trans set 


N 


1 


1 incl 


seg 1 


1 Control no. ’ 


L 




1 


i A16 i 


1 A17 I 






1 n an 


01/06 | 


| M AN 


04/09 | 
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APPENDIX C 

AUTOMATED UNIT EQUIPMENT LISTINGS (AUELS) 

This appendix contains Automated Unit Equipment 
Listings. The data in these listings was used in the demon- 
stration of the EDI concept, as described in Chapter IV. It 
should be noted that, although these two listings contain 
data from different units (Ft. Meade and Ft. Ord) , the data 
from both was transmitted in one transaction set as shown in 
Figure 4.3. 
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